Fixed issue #15192 #15241

lkshayb · 2025-07-10T14:09:05Z

Fixes #15192 by adding checks for no_std while giving out Box recommendation

changelog: [`large_enum_variant`]: Dont suggest `Box` in `no_std` mode

rustbot · 2025-07-10T14:09:11Z

r? @y21

rustbot has assigned @y21.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

github-actions · 2025-07-10T14:26:54Z

Lintcheck changes for b738d96

Lint	Added	Removed	Changed
`clippy::large_enum_variant`	0	0	13

This comment will be updated if you push new changes

samueltardieu · 2025-07-10T14:31:29Z

The changelog line in the PR description should contain the lint name in square brackets and quotes, such as in

changelog: [`large_enum_variant`]: do not suggest `Box` in `no_std` mode

(note also the quotes around Box and no_std)

This way it will be easily transformed into a link to the lint description when integrated in CHANGELOG.md when we issue the release notes.

lkshayb · 2025-07-10T14:42:49Z

@samueltardieu Thanks ! I've updated the changelog line as suggested .

y21

Hmm, I personally feel like the help message for what we're expecting the user to do to resolve the lint (introduce indirection for example by boxing) was still helpful as a hint.

Even in #![no_std] crates, one can still use extern crate alloc and use alloc::boxed::Box<_> that way (and I'd expect in practice this suggestion is very often still applicable), and even if the user doesn't have the alloc crate, I'd expect there would still be some other moral equivalent to introduce indirection

What do you think about instead of omitting this entirely in #![no_std] crates, actually "downgrade" the suggestion to just the help message, so it still hints to the user what they can do about it. We could also slightly change the message in case the user really can't use Box<_>. I'm thinking of something like:

help: consider boxing the large fields or introducing indirection in some other way to reduce the total size of the enum

y21 · 2025-07-10T23:35:17Z

tests/ui/large_enum_variant_no_std.rs

@@ -0,0 +1,16 @@
+#![no_std]
+#![no_main]


Tests are built as library crates, so you should be able to largely simplify this. The #![no_main] and panic handling code shouldn't be needed.

#![no_std] #![warn(clippy::large_enum_variant)] enum Myenum { //~^ ERROR: large size difference between variants Small(u8), Large([u8; 1024]), }

lkshayb · 2025-07-11T03:06:08Z

@y21 Thanks for the feedback . You are correct that a downgraded help message should be used . I will update my pull request to follow the same and also I'll edit out the panic handler and #[no_main].

lkshayb · 2025-07-11T03:43:13Z

@y21 I have implemented the suggestions you made . Please review it now.

lkshayb · 2025-07-16T03:41:52Z

@rustbot r? @y21

rustbot · 2025-07-16T03:41:55Z

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

y21

Can you also squash the commits into one?

y21 · 2025-07-16T15:46:39Z

clippy_lints/src/large_enum_variant.rs

@@ -149,7 +150,9 @@ impl<'tcx> LateLintPass<'tcx> for LargeEnumVariant {
                                return;
                            }
                        }
-                        diag.span_help(def.variants[variants_size[0].ind].span, help_text);
+                        if !is_no_std_crate(cx) {


Is this if here on purpose? My suggestion was to always at least show the help message, no matter what, as a guidance in case the user has some other way to add indirection, even without access to alloc.

As is implemented right now, it will still suppress the help message entirely in #![no_std] (as can be seen in the test)

Actually, looking at the git history on this branch, it looks like this was correct in lkshayb@0ac806d , but was then later reverted again in lkshayb@3e6d575

Thx @y21 for pointing this out . I've updated the pr now . and also squashed all the commits into one.

lkshayb · 2025-07-18T10:25:40Z

@y21 I've implemented the changes and squashed all the commits into one , please review now .

y21

Thanks!

y21 · 2025-07-19T17:11:51Z

Ah, looks like there's a 32-bit stderr of the test that wasn't blessed. They're a bit annoying to bless on 64 bit, but in this case since it's just the help message that changed everywhere, you could also just do a manual replace in tests/ui/large_enum_variant.32bit.stderr.

Also, while you're fixing that, minor nit: could you also reword the commit to something more descriptive? Thanks!

- Updated the `help:` text to include a more general suggestion - Ensures compatibility with `#[no_std]` environments where boxing is still possible via `alloc`.

lkshayb · 2025-07-20T08:32:36Z

@y21 I've blessed the 32 bit stederr manually and also changed the commit message .

rustbot assigned y21 Jul 10, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jul 10, 2025

y21 reviewed Jul 10, 2025

View reviewed changes